This chapter describes how the policy feature interacts with other router software components to make decisions about QOS, security, or both. It also describes the concepts and specific configuration commands related to the policy feature. The policy feature also allows an LDAP directory server to be used as a central repository for policy information. The concepts and configuration steps needed to enable the LDAP functions are also described in this chapter. The following topics discuss these concepts, the way in which routers enforce policies, and also provide examples.
The policy feature facilitates the management of IPv4 traffic in a network. You may configure policies for very simple filter rules (drop or pass) or for complex security and QOS scenarios. The combination of policies determines how routers handle IPv4 traffic in a network.
The policy implementation in this family of routers constitutes the basis for policy decisions and the means of enforcing them. These concepts are often referred to as a policy decision point (PDP) and a policy enforcement point (PEP).
The policy database, which resides in the router's memory, is comprised of the set of policies loaded from local configuration and policies that have been read from LDAP. The policy database is built under the following conditions:
The policy database serves as the PDP, and consists of a set of policies that determine how the policy feature-related components handle packets. When a policy results in a decision (based on information such as the time of day, IP packet information, and protocol-specific information such as identification), the decision is passed to the enforcement component (PEP) to carry out the action. Figure 26 shows the relationship of these components.
Figure 26. IP Packet Flow and the Policy Database
|
IP Packets first must pass the input packet filter before any other actions can be taken. If the input packet filter has rules present then the packet may have some action taken on it. If there is a filter match that excludes the packet or there is no match found in the input packet filter then the packet is dropped.
If the packet passes the input packet filter then it goes to a demultiplexing filter, which checks to see whether the packet is locally destined. If it is, then depending on the type of packet it is passed to other modules. These modules may be IPSec, IKE, RSVP, or others. If the packet is locally destined for IPSec, IKE, or RSVP then those modules may query the policy database to determine which action to take.
If the packet is not locally destined then it is given to the forwarding engine and a routing decision is made. If the routing decision does not drop the packet (Policy Based Routing may decide to drop the packet), then the packet goes to the output packet filter. If filter rules are present in the output packet then the packet may have address translation performed (NAT), may be passed or may be dropped. If no filter rules are present then the packet is passed. If filter rules are present and no match is found then the packet is dropped. If the packet passes the Output Packet filter then the IP Engine queries the policy database to determine whether any other actions should be performed on this packet.
| Note: | If the input and output packet filters are enabled for an interface(s), and packets that are to be controlled by the policy database are expected to traverse these interfaces, then a filter rule that includes these packets must be present in the input and output packet filters so they will not be dropped before the policy database is queried. One suggestion is to use to policy database to configure all the pass/drop rules and not to use the packet filters. |
When the IP forwarding engine queries the policy database, the following types of decision combinations may be returned:
If IPSec receives a packet then it must first decapsulate the packet and then decide whether the packet arrived in the correct IPSec tunnel (often referred to as the conformancy check). It does this by querying the policy database. The policy database may return the following types of decisions for this query:
IKE may query the policy database and have the Phase 1 IP policy
decisions shown in Table 36 returned.
Table 36. IKE Phase 1 Queries and the Decisions Returned
| Query Type | Decision |
|---|---|
| Message 1 (Main Mode) | No match found, drop packet |
| Message 1 (Main Mode) | Match found, negotiate with Phase 1 policy x |
| Message 5 (Main Mode) | No match found, stop negotiations with peer, drop packet |
| Message 5 (Main Mode) | No match found, stop negotiations with peer, drop packet |
| Message 5 (Main Mode) | Match found, policy x matched, finish Phase 1 |
| Message 5 (Main Mode) | Match found, policy y matched, stop current Phase 1 and initiate new Phase 1 with new policy |
| Message 1 (Aggressive Mode) | No match found, drop packet |
| Message 1 (Aggressive Mode) | Match found, policy x matched |
IKE may query the policy database and have the Phase 2 IP policy
decisions shown in Table 37 returned.
Table 37. IKE Phase 2 Queries and the Decisions Returned
| Query Type | Decision |
|---|---|
| Message 2 (responder) | No match found, drop packet |
| Message 2 (responder) | Match found, negotiate with policy x |
If a packet is an RSVP control message then RSVP queries the policy database to determine whether to accept or deny the reservation. If it is accepted then RSVP determines which attributes of the reservation to limit, based on the policy. Policies in the policy database can control the duration of the reservation, the amount of bandwidth that should be allocated, and the minimum delay to guarantee.
A policy is made up of a profile, which contains a set of packet attributes upon which to base decisions, actions to take if a packet's attributes match those in the profile, and a validity period during which the decisions are made and the actions are enforced. These items are explained in greater detail in the following topics:
The parts that make up a policy are distinct named objects. Policy objects may refer to one another, and as a group of related items they comprise a policy. By separating configuration information into separate distinct objects, you can reuse many of them across multiple policy definitions, thus saving time and reducing maintenance efforts. Individual policy objects are discussed in detail in the following topics.
The policy object describes which conditionals should be checked against, and if the checks match, which actions to enforce. The policy makes named references to the validity period and the profile. For the policy to be valid, these references are required. The policy must also make a named reference to one or more of the following actions: an IPSec manual-keyed tunnel object, an IPSec action, an ISAKMP action, an RSVP action, or a DiffServ action. Valid combinations are:
| Note: | In these combinations an IPSec manual tunnel cannot exist in the same policy definition as an IPSec action (IKE-negotiated IPSec tunnel), and an RSVP action must not be associated with any kind of IPSec action. If an IPSec action to secure packets is associated with a policy then you must also associate an ISAKMP action with the policy. |
Each policy also has a priority number associated with it (the higher the number in the priority attribute, the higher the priority). The priority determines whether this policy takes precedence over another policy. Typically, you only have to set this if two or more policies' profiles conflict with each other in some way. The policy with the more specific profile should have a higher priority. For example, suppose that one policy specifies that traffic from subnet A to subnet B is to be secured with IPSec (DES) and another policy specifies that traffic from point a' (a particular host inside of subnet A) to subnet B is to be secured with IPSec (3DES). The more specific policy (a' to B) should have a higher priority than the policy with A to B.
It is a good idea to designate initial priority values that are 5 or more digits apart to allow room for specifying additional priority values for conflicting policies later. Each policy also has an enabled attribute, which determines whether the policy is to be enabled when loaded into the policy database. If a policy match is found during a policy database search but the policy is disabled, then the next most specific policy is enforced.
The profile determines which information is to be used to select a particular policy. The profile consists of source address and destination address information, protocol information, and source and destination port information.
| Note: | When defining policies for IPSec/ISAKMP, each gateway providing the security must have a policy to define the security association. The profile on each gateway must associate the source with the destination and the destination with the source. The profile for an IPSec policy must specify the source address as the traffic to be encapsulated into the tunnel and the destination address must be at the remote end of the tunnel. |
The profile can also select based on the type-of-service (TOS) byte and the ingress and egress IP address. By default a packet received on any input interface and which leaves on any output interface is matched against the other selectors. In some cases, you may need the flexibility to specify exactly the interfaces on which the packet must arrive, and the interface on which the packet must leave. If you want this, then you must add interface-pair objects and associate the group name for the interface pair objects with the profile. You assign interface-pair objects to a group by giving them the same name. This allows you to specify combinations such as (any packet arriving on IPaddrX and leaving on any interface OR any packet coming in any interface and leaving on IPaddrX). This is particularly useful if you define a general drop rule for a public interface.
Interface Pair: Identifies the input interface and output interface. Specify the IP addresses for the interface for this selection. A value of 255.255.255.255 implies any interface.
If you want to use the profile to select an IPSec/ISAKMP policy, then you have the option of specifying the local ID to be sent during Phase 1, and the list of acceptable remote IDs during Phase 1 negotiations. By default, the local ID is the local tunnel endpoint for the IPSec/IKE traffic, and the remote ID list is Any. Optionally, you may specify the fully qualified domain name (FQDN), user FQDN, and key ID. Normally this is sufficient because all ISAKMP Phase 1 negotiations are authenticated with either public certificates or pre-shared keys. However, in some remote access situations in which the policy is wild-carded out for the destination addresses, it may be wise to specify a list of remote access users that are to be allowed access to network resources.
These users are still authenticated through the normal ISAKMP authentication methods, but the policy database performs an additional authentication step by ensuring that the local ID sent by the remote peer matches one of the IDs specified in the Remote User Group of the policy's profile. This is required if a public certificate authority (CA) is administering certificates to the general public, and the network administrator only wants a specific set of these users (for example, company employees) to have access. The remote user group is comprised of a list of users who belong to the same group. These users are entered by adding one or more USERs. A group of users can be making the group name for each user the same. This group can then optionally be associated with a profile.
The validity period specifies the life of the policy--the year, the months of the year, the days of the week, and the hours of the day that it is valid. This flexibility enables the network administrator to specify when a policy is valid, for example "all the time" or "only this year, during the months of January, February and March, on Monday through Friday, from 9 AM to 5 PM." When a policy in the policy database becomes invalid, the next most specific policy will be enforced. Thus you could define a policy that specifies on Monday through Friday from 9 am to 5 am to secure all traffic from subnet A to subnet B, and at any other time drop all traffic from subnet A to subnet B. In this case the first policy must have a higher priority (specified when you enter the Talk 5 add policy command).
The DiffServ action describes the quality of service that is to be provided to packets that match a policy that specifies a DiffServ action. You may configure the DiffServ action to drop packets. You may also use the DiffServ action to map packets into relative qualities of service. You may configure the bandwidth allocated as a percentage of output bandwidth or as an absolute value in Kbps. You must specify whether the best effort/assured queue or the premium queue is to provide the bandwidth allocation. For more information on these queues and how to define them, see Using the Differentiated Services Feature and Configuring and Monitoring the Differentiated Services Feature.
The DiffServ action also specifies how to mark the TOS byte before it is sent on the egress interface. By default the TOS byte is not marked. It is useful to mark the packets at some point in the network based on the information in the IP packet header. Once the classification has been determined, since TOS byte marking has already been done, then the rest of the hops in the network can simply look at the new TOS byte to determine which QOS to apply to the packet. Looking at the TOS byte alone is much more efficient and may be necessary to achieve high performance in the DiffServ backbone.
The RSVP action specifies whether to permit or deny RSVP flows if an RSVP reservation occurs and the reservation request matches the profile of the policy. If you want to permit the reservation, then the RSVP action also states the allowed duration of the reservation, the allowed bandwidth, and optionally, a reference to a DiffServ action. The reference to the DiffServ action enables RSVP to determine how to mark the TOS byte before the packet leaves the router. This is useful when packets pass from an RSVP network into a DiffServ network. RSVP can provide the QOS up to the RSVP boundary and then mark the TOS byte appropriately so the DiffServ network can apply the correct bandwidth.
The IPSec action may specify either a drop, pass, or secure action. If the action is drop, then all packets matching this policy are dropped. If the action is pass with no security, then all packets are passed in the clear. If the action is pass with security, then all packets are secured by means of the security association (SA) specified by this action. The IPSec action also contains the IP addresses of the tunnel endpoints for the IPSec tunnel and IKE SAs.
The attributes of the SA are determined by the IPSec proposals that the IPSec action references. The IPSec action may specify multiple IPSec proposals and they are sent and checked against in the order they are specified. Having multiple proposals in an IPSec action allows the configuration to contain all the acceptable combinations of security, thereby reducing the number of potential configuration mismatches between VPN gateways.
The IPSec proposal contains the information about which ESP, AH, (or both) transform to propose or check against during Phase 2 ISAKMP negotiations. If you require perfect forward secrecy (a fresh Diffie Hellman calculation), then the IPSec proposal identifies which DH group to use. The transforms that the IPSec proposal references are sent or checked against in the order in which they are specified. The first ESP or AH transform in the list must be the one that is most appropriate to use. If more than one transform is in the list, then each one is compared to the peer's list of transforms to find a match. If none of the configured transforms match the peer's list then the negotiation fails. The IPSec proposal may list a combination of AH and ESP transforms, but the only valid combinations are:
The attributes of the IPSec transform contain information about the IPSec encryption and authentication parameters and also specify how often the keys are refreshed. The transform is either AH (authentication only) or ESP (encryption, authentication, or both) and may be configured to operate in either tunnel or transport mode.
The ISAKMP action specifies the key management information for Phase 1. It specifies whether the Phase 1 negotiations are to start in main mode (provides identity protection) or in aggressive mode. It also specifies whether the Phase 1 security association is to be negotiated at device start-up or on demand. The ISAKMP action also must reference one or more ISAKMP proposals. The first reference must be to the most acceptable ISAKMP proposal.
The ISAKMP proposal specifies the encryption and authentication attributes of the Phase 1 security association. It also specifies which Diffie Hellman group to use to generate the keys, and the life of the Phase 1 security association. You must select the authentication method in the ISAKMP proposal. It can be either pre-shared key or certificate mode.
You must configure a USER for any policy that uses an ISAKMP negotiation with pre-shared key as the authentication method. The USER configuration identifies the pre-shared key to use for the ISAKMP peer. The user object contains the identifying information for a remote ISAKMP peer, that is IP address, FQDN, user FQDN or key ID, and which method the user wants to use for authentication. You may select either pre-shared key or certificate mode. If you select pre-shared key, then you must also specify whether the pre-shared key must be entered in ASCII or hexadecimal, and the value of the key. USERs may be grouped together by assigning them to the same group name. This group can then optionally be associated with a policy's profile to perform a more strict policy lookup for Phase 1.
The IPSec manual-keyed tunnel is a static configuration of the encryption and authentication parameters. No negotiation is performed for the tunnel so both peers must have exactly the same configuration. The keys are actually entered as part of this configuration and must match on both sides of the tunnel. Since no negotiation is performed in this mode, the keys are never refreshed. For more information about IPSec manual-keyed tunnels, see the discussion of the IPSec feature in "Using IP Security".
Figure 27 shows the relationship between policy configuration objects.
Figure 27. Relationship of Policy Configuration Objects
 |
This family of routers allows a Lightweight Directory Access Protocol (LDAP) server to be the repository of policy information (the policy database). LDAP is a protocol that allows a directory server to be searched and modified. LDAP is a lightweight version of the X.500 standard. The routers support the ability to search for (but not modify) information in the directory server. The policy search agent in the router retrieves all the policy information in the directory server that is intended for that device. Any LDAP server operating at LDAP Version 2 or 3 works with the implementation in the router. An important advantage of using a directory server to store policy information as opposed to more traditional methods of locally stored configuration is the ability to make a change in one place and have that change applied across all the devices in the extended network. This includes devices in the administrative domain as well as devices across public boundaries.
For example, suppose you have an IPSec transform definition that resides in the directory. If you want to change the corporate policy for encryption from DES to 3DES, this would normally require a change in every device configuration across each network boundary. If you use the directory to deploy the policies then you only have to change one IPSec transform. Each policy-enabled device in your network would then need to rebuild the database. As another example, suppose you need to change a DiffServ action named "GoldService" to increase the bandwidth value from 40% to 45% of bandwidth. The LDAP server and policy infrastructure allow these types of configuration changes to scale much better and they reduce configuration mismatches.
If you are the network administrator, you may also take advantage of the ability to refresh the database automatically at a specified time each day. Select this option by entering the policy feature's set refresh command. You may specify whether refreshing is enabled or not and, if enabled, the time at which the database is to refresh. This option is useful for making automated changes. For example, suppose that you must add a new policy so that the marketing department in the U.S. can talk to the development department in Japan across the Internet, and that the security gateways are SG1 and SG2. You can simply enter this information into the directory, and at midnight SG1 and SG2 automatically pick up this change if they are enabled for automatic refresh.
The LDAP policy search engine enables you to specify the security level to be used while building the policy database. You define these security options with the policy feature's set default command. The options are:
In some situations either of the first two options are sufficient. However, if the LDAP traffic will traverse the public infrastructure, you should secure and authenticate the information by selecting the third option. If you do this, you must select Phase 1 and Phase 2 authentication and encryption options. You must also enter the IP addresses for the tunnel endpoints (primary and secondary LDAP servers). This boot-strap IKE/IPSec tunnel will be negotiated before any LDAP traffic is sent. This feature allows you to establish the configuration shown in Figure 28.
Figure 28. Securing Traffic Across the Internet
 |
This figure shows an LDAP server on Subnet A in the corporate network. SG1, SG2, and SG3 are fetching their policies from the LDAP server. The policy search for SG2 and SG3 occurs across the Internet and is protected through IPSec.
The configuration information required for the policy database to successfully retrieve the policies from the directory is:
After you have entered this configuration information, the next time the policy database is refreshed an attempt is made to interrogate the directory server for policy information. The policy database allows for a combination of locally configured policies and rules read from the LDAP server. If two rules are found to be conflicting and they are at the same priority, then the rule read from the local configuration take precedence over the rule read from the directory server.
The LDAP schema is the set of rules and information making up the class and attribute definitions that determine the contents of entries in the directory. Typically the LDAP schema is written in ASN1 syntax, similar to SNMP MIBs. The policy schema that this family of routers supports is a work that comprises pre-standard efforts being done in the IETF. It is based on the standards track work being done by the IPSec and Policy Working Groups in the IETF and the Policy Working Group in the DMTF. The policy schema closely matches the existing configuration objects in the policy feature on the router. The policy schema definition files and LDAP server configuration files may be found by accessing the following URL: http://www.networking.ibm.com/support. Please select the router product you want and then select the Downloads link. Figure 29 shows the overall structure of the policy schema.
Figure 29. Policy Schema Structure
 |
The DeviceProfile and DevicePolicyRules are two key objects in the policy schema. They enable the policy search agent to locate the policies needed for the device. The DeviceProfile contains information about the device's administrative IP address and a mandatory DevicePolicyRules reference. You may group devices together into one DeviceProfile or each device in the network can have its own DeviceProfile. The choice you make depends on whether more than one device in the network must fetch the same set of rules. Typically, for security gateways this is not the case because every gateway has a different tunnel endpoint. For QOS-only devices, it is conceivable that all devices in a group would all read the same set of policies.
The DevicePolicyRules object is retrieved based on the value in the DeviceProfile that is fetched for the device. Once the DevicePolicyRules object has been retrieved, then the list of PolicyRules for that device can be retrieved. If any object is not found or if an error is detected during a consistency check on a object then the search is aborted and messages are displayed to the ELS (PLCY messages) identifying the error. If an error occurs, the network administrator may configure one of the following choices to handle it:
In either case, the search is attempted again at the configured retry interval. If the primary LDAP server cannot be contacted, then after 5 attempts the secondary server is tried. If the secondary server cannot be reached, then after 5 attempts the primary server is tried again. You can specify the retry interval with the policy feature's set ldap retry-interval command. If a search is failing because of network latency, you may change the search timeout from the default of 3 seconds using the policy feature's set ldap search-timeout command.
Configure a policy to specify how you want the network to operate. The router translates the policy information into a set of rules that it compares to traffic flows. In the past you may have done this manually by defining inbound and outbound packet filters for each traffic pattern. The policy database eliminates this, because with it you only configure a single policy.
Most of the work is done internally each time the policy database is built. In some cases a router translates a policy directly into a single rule. In the case of ISAKMP/IPSec, it translates a policy into five rules. Five rules are needed to account for the traffic directions (in and out) and for the control flows that occur during Phase 1 and Phase 2 of IKE negotiations. The relationship between policies and rules is as follows:
One DiffServ policy > One DiffServ rule
One RSVP policy > One RSVP rule
One ISAKMP/IPSec policy > Five ISAKMP/IPSec rules
Example: Secure the traffic from subnet A to subnet B; the tunnel endpoints are SGa and SGb
One IPSec manual-keyed tunnel > Two IPSec rules
Example: Secure the traffic from subnet A to subnet B; the tunnel endpoints are SGa and SGb.
You may view these rules using the policy feature's Talk 5 list rule command.
The following examples show how you can use the policy feature to configure the routers in a network. First, access the policy feature as shown:
* talk 6 Config>feature policy IP Network Policy configuration
You may enter policy information in either of two ways. The first way is to define the individual policy objects and then group them together. To use this method, first define the IPSec transforms, then the IPSec proposal (which refers to the IPSec transforms). Then define the IPSec action (which refers to the IPSec proposals), and so forth until you completely define the policy. Using Figure 30 as a reference, this method starts at the right side of the policy objects and works its way to the left.
The second approach, which you may find easier, is to define the high-level policy options first, and as you are prompted, enter the definitions for the individual policy objects as you go along. A sample configuration procedure follows Figure 30, and uses values that correspond to those in the figure. It uses the left-to-right method and starts with the add policy command.
If an object was defined previously that meets your needs, then you can reuse it instead of creating a new definition. For example, if a validity period for allTheTime was configured for a previous policy, then you may reuse it. The following procedure shows the entire process, but does not demonstrate the reuse of previously defined policy information. For an example of using previously defined information, see IPSec/ISAKMP Only Policy.
Figure 30. Configuring IPSec/ISAKMP with QOS
 |
The policy configuration scenario described in the following text is from SG1's perspective. The policy statement is:
Secure the traffic from subnet 11 to subnet 12 with the tunnel endpoints being SG1 and SG2, and provide a QOS for the traffic in this tunnel by means of DiffServ GoldService
Policy config>add policy Enter a Name (1-29 characters) for this Policy []? examplePolicySecure11to12 Enter the priority of this policy (This number is used to determine the policy to enforce in the event of policy conflicts) [5]? 10
List of Profiles: 0: New Profile Enter number of the profile for this policy [0]?
Enter a Name (1-29 characters) for this Profile []? trafficFrom11NetTo12Net
Source Address Format (1:NetMask, 2:Range, 3:Single Addr) [1]?
Enter IPV4 Source Address [0.0.0.0]? 11.0.0.0
Enter IPV4 Source Mask [255.0.0.0]?
Destination Address Format (1:NetMask, 2:Range, 3:Single Addr) [1]?
Enter IPV4 Destination Address [0.0.0.0]? 12.0.0.0
Enter IPV4 Destination Mask [255.0.0.0]?
Protocol IDs:
1) TCP
2) UDP
3) All Protocols
4) Specify Range
Select the protocol to filter on (1-4) [3]?
Enter the Starting value for the Source Port [0]?
Enter the Ending value for the Source Port [65535]?
Enter the Starting value for the Destination Port [0]?
Enter the Ending value for the Destination Port [65535]?
Enter the Mask to be applied to the Received DS-byte [0]?
Enter the value to match against after the Mask has
been applied to the Received DS-byte [0]?
Configure local and remote ID's for ISAKMP? [No]:
Limit this profile to specific interface(s)? [No]:
Here is the Profile you specified...
Profile Name = trafficFrom11NetTo12Net
sAddr:Mask= 11.0.0.0 : 255.0.0.0 sPort= 0 : 65535
dAddr:Mask= 12.0.0.0 : 255.0.0.0 dPort= 0 : 65535
proto = 0 : 255
TOS = x00 : x00
Remote Grp=All Users
Is this correct? [Yes]:
List of Profiles: 0: New Profile 1: trafficFrom11NetTo12Net Enter number of the profile for this policy [1]? 1
List of Validity Periods: 0: New Validity Period Enter number of the validity period for this policy [0]?
Enter a Name (1-29 characters) for this Policy Valid Profile []?
MonToFri-9am:5pm-1999
Enter the lifetime of this policy. Please input the
information in the following format:
yyyymmddhhmmss:yyyymmddhhmmss OR '*' denotes forever.
[*]? 19990101000000:19991231000000
During which months should policies containing this profile
be valid. Please input any sequence of months by typing in
the first three letters of each month with a space in between
each entry, or type ALL to signify year round.
[ALL]?
During which days should policies containing this profile
be valid. Please input any sequence of days by typing in
the first three letters of each day with a space in between
each entry, or type ALL to signify all week
[ALL]? mon tue wed thu fri
Enter the starting time (hh:mm:ss or * denotes all day)
[*]? 00:00:00
Enter the ending time (hh:mm:ss)
[00:00:00]? 17:00:00
Here is the Policy Validity Profile you specified...
Validity Name = MonToFri-9am:5pm-1999
Duration = 19990101000000 : 19991231000000
Months = ALL
Days = MON TUE WED THU FRI
Hours = 09:00:00 : 17:00:00
Is this correct? [Yes]:
List of Validity Periods: 0: New Validity Period 1: MonToFri-9am:5pm-1999 Enter number of the validity period for this policy [1]? 1 Should this policy enforce an IPSEC action? [No]: yes
IPSEC Actions: 0: New IPSEC Action Enter the Number of the IPSEC Action [0]?
Enter a Name (1-29 characters) for this IPsec Action []? secure11NetTo12Net
List of IPsec Security Action types:
1) Block (block connection)
2) Permit
Select the Security Action type (1-2) [2]? 2
Should the traffic flow into a secure tunnel or in the clear:
1) Clear
2) Secure Tunnel
[2]?
Enter Tunnel Start Point IPV4 Address
[11.0.0.5]? 1.1.1.1
Enter Tunnel End Point IPV4 Address (0.0.0.0 for Remote Access)
[0.0.0.0]? 1.1.1.2
Does this IPSEC tunnel flow within another IPSEC tunnel? [No]:
Percentage of SA lifesize/lifetime to use as the acceptable minimum [75]?
Security Association Refresh Threshold, in percent (1-100) [85]?
Options for DF Bit in outer header (tunnel mode):
1) Copy
2) Set
3) Clear
Enter choice (1-3) [1]?
Enable Replay prevention (1=enable, 2=disable) [2]?
Do you want to negotiate the security association at
system initialization(Y-N)? [No]:
You must choose the proposals to be sent/checked against during phase 2
negotiations. Proposals should be entered in order of priority.
List of IPSEC Proposals: 0: New Proposal Enter the Number of the IPSEC Proposal [0]?
Enter a Name (1-29 characters) for this IPsec Proposal []? genP2Proposal Does this proposal require Perfect Forward Secrecy?(Y-N)? [No]: Do you wish to enter any AH transforms for this proposal? [No]: Do you wish to enter any ESP transforms for this proposal? [No]: yes
List of ESP Transforms: 0: New Transform Enter the Number of the ESP transform [0]? 0
Enter a Name (1-29 characters) for this IPsec Transform []? esp3DESwSHA
List of Protocol IDs:
1) IPSEC AH
2) IPSEC ESP
Select the Protocol ID (1-2) [1]? 2
List of Encapsulation Modes:
1) Tunnel
2) Transport
Select the Encapsulation Mode(1-2) [1]? 1
List of IPsec Authentication Algorithms:
0) None
1) HMAC-MD5
2) HMAC_SHA
Select the ESP Authentication Algorithm (0-2) [2]? 2
List of ESP Cipher Algorithms:
1) ESP DES
2) ESP 3DES
3) ESP CDMF
4) ESP NULL
Select the ESP Cipher Algorithm (1-4) [1]? 2
Security Association Lifesize, in kilobytes (1024-65535) [50000]?
Security Association Lifetime, in seconds (120-65535) [3600]?
Here is the IPSec transform you specified...
Transform Name = esp3DESwSHA
Type =ESP Mode =Tunnel LifeSize= 50000 LifeTime= 3600
Auth =SHA Encr =3DES
Is this correct? [Yes]:
List of ESP Transforms: 0: New Transform 1: esp3DESwSHA Enter the Number of the ESP transform [1]? Do you wish to add another ESP transform to this proposal? [Yes]: no Here is the IPSec proposal you specified... Name = genP2Proposal Pfs = N ESP Transforms: esp3DESwSHA Is this correct? [Yes]:
List of IPSEC Proposals: 0: New Proposal 1: genP2Proposal Enter the Number of the IPSEC Proposal [1]? Are there any more Proposal definitions for this IPSEC Action? [No]: Here is the IPSec Action you specified... IPSECAction Name = secure11NetTo12Net Tunnel Start:End = 1.1.1.1 : 1.1.1.2 Tunnel In Tunnel = No Min Percent of SA Life = 75 Refresh Threshold = 85 % Autostart = No DF Bit = COPY Replay Prevention = Disabled IPSEC Proposals: genP2Proposal Is this correct? [Yes]:
IPSEC Actions: 0: New IPSEC Action 1: secure11NetTo12Net Enter the Number of the IPSEC Action [1]? 1
ISAKMP Actions: 0: New ISAKMP Action Enter the Number of the ISAKMP Action [0]?
Enter a Name (1-29 characters) for this ISAKMP Action []? genPhase1Action
List of ISAKMP Exchange Modes:
1) Main
2) Aggressive
Enter Exchange Mode (1-2) [1]?
Percentage of SA lifesize/lifetime to use as the acceptable minimum [75]?
ISAKMP Connection Lifesize, in kilobytes (100-65535) [5000]?
ISAKMP Connection Lifetime, in seconds (120-65535) [30000]?
Do you want to negotiate the security association at
system initialization(Y-N)? [Yes]: no
You must choose the proposals to be sent/checked against during phase 1
negotiations. Proposals should be entered in order of priority.
List of ISAKMP Proposals: 0: New Proposal
Enter the Number of the ISAKMP Proposal [0]?
Enter a Name (1-29 characters) for this ISAKMP Proposal []? genP1Proposal
List of Authentication Methods:
1) Pre-Shared Key
2) RSA SIG
Select the authentication method (1-2) [1]? 2
List of Hashing Algorithms:
1) MD5
2) SHA
Select the hashing algorithm(1-2) [1]? 2
List of Cipher Algorithms:
1) DES
2) 3DES
Select the Cipher Algorithm (1-2) [1]? 2
Security Association Lifesize, in kilobytes (100-65535) [1000]?
Security Association Lifetime, in seconds (120-65535) [15000]?
List of Diffie Hellman Groups:
1) Diffie Hellman Group 1
2) Diffie Hellman Group 2
Select the Diffie Hellman Group ID from this proposal (1-2) [1]?
Here is the ISAKMP Proposal you specified...
Name = genP1Proposal
AuthMethod = Pre-Shared Key
LifeSize = 1000
LifeTime = 15000
DHGroupID = 1
Hash Algo = SHA
Encr Algo = 3DES CB
Is this correct? [Yes]:
List of ISAKMP Proposals: 0: New Proposal 1: genP1Proposal Enter the Number of the ISAKMP Proposal [1]? Are there any more Proposal definitions for this ISAKMP Action? [No]: Here is the ISAKMP Action you specified... ISAKMP Name = genPhase1Action Mode = Main Min Percent of SA Life = 75 Conn LifeSize:LifeTime = 5000 : 30000 Autostart = No ISAKMP Proposals: genP1Proposal Is this correct? [Yes]:
ISAKMP Actions: 0: New ISAKMP Action 1: genPhase1Action Enter the Number of the ISAKMP Action [1]? Do you wish to Map a DiffServ Action to this Policy? [No]: yes
DiffServ Actions: 0: New DiffServ Action Enter the Number of the DiffServ Action [0]?
Enter a Name (1-29 characters) for this DiffServ Action []? GoldService Enter the permission level for packets matching this DiffServ Action (1. Permit, 2. Deny) [2]? 1 List of DiffServ Queues: 1) Premium 2) Assured/BE Enter the Queue Number(1-2) for outgoing packets matching this DiffServ Action [2]? 2 How do you want to specify the bandwidth allocated to this service? Enter absolute kbps(1) or percentage of output bandwidth(2) [2]? Enter the percentage of output bandwidth allocated to this service [10]? 40 Transmitted DS-byte mask [0]? Transmitted DS-byte modify value [0]? Here is the DiffServ Action you specified... DiffServ Name = GoldService Type =Permit TOS mask:modify=x00:x00 Queue:BwShare =Assured : 40 % Is this correct? [Yes]:
DiffServ Actions: 0: New DiffServ Action 1: GoldService Enter the Number of the DiffServ Action [1]? 1 Policy Enabled/Disabled (1. Enabled, 2. Disabled) [1]? Here is the Policy you specified... Policy Name = examplePolicySecure11to12 State:Priority =Enabled : 10 Profile =trafficFrom10NetTo12Net Valid Period =MonToFri-9am:5pm-1999 IPSEC Action =secure11NetTo12Net ISAKMP Action =genPhase1Action DiffServ Action=GoldService Is this correct? [Yes]:
You must enable and configure DiffServ in feature DS before QOS can be ensured for this policy
Policy config>add user Choose from the following ways to identify a user: 1: IP Address 2: Fully Qualified Domain Name 3: User Fully Qualified Domain Name 4: Key ID (Any string) Enter your choice(1-4) [1]? Enter the IP Address that distinguishes this user [0.0.0.0]? 1.1.1.2 Group to include this user in []? peers Authenticate user with 1:pre-shared key or 2: Public Certificate [1]? Mode to enter key (1=ASCII, 2=HEX) [1]? Enter the Pre-Shared Key (an even number of 2-128 ascii chars): Enter the Pre-Shared Key again (10 characters) in ascii: Here is the User Information you specified... Name = 1.1.1.2 Type = IPV4 Addr Group =peers Auth Mode =Pre-Shared Key Key(Ascii)=exampleKey Is this correct? [Yes]:
Policy config>list all
Configured Policies....
Policy Name = examplePolicySecure11to12
State:Priority =Enabled : 10
Profile =trafficFrom11NetTo12Net
Valid Period =MonToFri-9am:5pm-1999
IPSEC Action =secure11NetTo12Net
ISAKMP Action =genPhase1Action
DiffServ Action=GoldService
--More--
Configured Profiles....
Profile Name = trafficFrom11NetTo12Net
sAddr:Mask= 11.0.0.0 : 255.0.0.0 sPort= 0 : 65535
dAddr:Mask= 12.0.0.0 : 255.0.0.0 dPort= 0 : 65535
proto = 0 : 255
TOS = x00 : x00
Remote Grp=All Users
--More--
Configured Validity Periods
Validity Name = MonToFri-9am:5pm-1999
Duration = 19990101000000 : 19991231000000
Months = ALL
Days = MON TUE WED THU FRI
Hours = 09:00:00 : 17:00:00
--More--
Configured DiffServ Actions....
DiffServ Name = GoldService Type =Permit
TOS mask:modify=x00:x00
Queue:BwShare =Assured : 40 %
--More--
Configured IPSEC Actions....
IPSECAction Name = secure11NetTo12Net
Tunnel Start:End = 1.1.1.1 : 1.1.1.2
Tunnel In Tunnel = No
Min Percent of SA Life = 75
Refresh Threshold = 85 %
Autostart = No
DF Bit = COPY
Replay Prevention = Disabled
IPSEC Proposals:
genP2Proposal
--More--
Configured IPSEC Proposals....
Name = genP2Proposal
Pfs = N
ESP Transforms:
esp3DESwSHA
--More--
Configured IPSEC Transforms....
Transform Name = esp3DESwSHA
Type =ESP Mode =Tunnel LifeSize= 50000 LifeTime= 3600
Auth =SHA Encr =3DES
--More--
Configured ISAKMP Actions....
ISAKMP Name = genPhase1Action
Mode = Main
Min Percent of SA Life = 75
Conn LifeSize:LifeTime = 5000 : 30000
Autostart = No
ISAKMP Proposals:
genP1Proposal
--More--
Configured ISAKMP Proposals....
Name = genP1Proposal
AuthMethod = Pre-Shared Key
LifeSize = 1000
LifeTime = 15000
DHGroupID = 1
Hash Algo = SHA
Encr Algo = 3DES CB
--More--
Configured Policy Users....
Name = 1.1.1.2
Type = IPV4 Addr
Group =peers
Auth Mode =Pre-Shared Key
Key(Ascii)=exampleKey
--More--
Configured Manual IPSEC Tunnels....
IPv4 Tunnels
------------------------------------------------------------------------------
ID Name Local IPv4 Addr Rem IPv4 Addr Mode State
------ --------------- --------------- --------------- ----- --------
A sample configuration procedure, which follows Figure 31 and uses values that correspond to those in the figure, uses the left-to-right method and shows how to build on the previous sample procedure by reusing information that the previous one created.
Figure 31. Configuring IPSec and Reusing a Previous Definition
 |
The policy configuration scenario described in the following text is from SG1's perspective. The policy statement in this scenario is:
Secure the traffic from subnet 11 to subnet 13 (TCP traffic only) with the tunnel endpoints being SG1 and SG3, and provide no QOS.
Policy config>add policy
Enter a Name (1-29 characters) for this Policy []? examplePolicySecure11to13
Enter the priority of this policy (This number is used to
determine the policy to enforce in the event of policy conflicts) [5]? 10
List of Profiles:
0: New Profile
1: trafficFrom10NetTo12Net
Enter number of the profile for this policy [1]? 0
Enter a Name (1-29 characters) for this Profile []? trafficFrom11NetTo13Net
Source Address Format (1:NetMask, 2:Range, 3:Single Addr) [1]?
Enter IPV4 Source Address [0.0.0.0]? 11.0.0.0
Enter IPV4 Source Mask [255.0.0.0]?
Destination Address Format (1:NetMask, 2:Range, 3:Single Addr) [1]?
Enter IPV4 Destination Address [0.0.0.0]? 13.0.0.0
Enter IPV4 Destination Mask [255.0.0.0]?
Protocol IDs:
1) TCP
2) UDP
3) All Protocols
4) Specify Range
Select the protocol to filter on (1-4) [3]? 1
Enter the Starting value for the Source Port [0]?
Enter the Ending value for the Source Port [65535]?
Enter the Starting value for the Destination Port [0]?
Enter the Ending value for the Destination Port [65535]?
Enter the Mask to be applied to the Received DS-byte [0]?
Enter the value to match against after the Mask has
been applied to the Received DS-byte [0]?
Configure local and remote ID's for ISAKMP? [No]:
Limit this profile to specific interface(s)? [No]:
Here is the Profile you specified...
Profile Name = trafficFrom11NetTo13Net
sAddr:Mask= 11.0.0.0 : 255.0.0.0 sPort= 0 : 65535
dAddr:Mask= 13.0.0.0 : 255.0.0.0 dPort= 0 : 65535
proto = 6 : 6
TOS = x00 : x00
Remote Grp=All Users
Is this correct? [Yes]:
List of Profiles:
0: New Profile
1: trafficFrom10NetTo12Net
2: trafficFrom11NetTo13Net
Enter number of the profile for this policy [1]? 2
List of Validity Periods:
0: New Validity Period
1: MonToFri-9am:5pm-1999
Enter number of the validity period for this policy [1]?
Should this policy enforce an IPSEC action? [No]: yes
IPSEC Actions:
0: New IPSEC Action
1: secure11NetTo12Net
Enter the Number of the IPSEC Action [1]? 0
Enter a Name (1-29 characters) for this IPsec Action []? secure11To13
List of IPsec Security Action types:
1) Block (block connection)
2) Permit
Select the Security Action type (1-2) [2]?
Should the traffic flow into a secure tunnel or in the clear:
1) Clear
2) Secure Tunnel
[2]?
Enter Tunnel Start Point IPV4 Address
[11.0.0.5]? 1.1.1.1
Enter Tunnel End Point IPV4 Address (0.0.0.0 for Remote Access)
[0.0.0.0]? 1.1.1.3
Does this IPSEC tunnel flow within another IPSEC tunnel? [No]:
Percentage of SA lifesize/lifetime to use as the acceptable minimum [75]?
Security Association Refresh Threshold, in percent (1-100) [85]?
Options for DF Bit in outer header (tunnel mode):
1) Copy
2) Set
3) Clear
Enter choice (1-3) [1]?
Enable Replay prevention (1=enable, 2=disable) [2]?
Do you want to negotiate the security association at
system initialization(Y-N)? [No]:
You must choose the proposals to be sent/checked against during phase 2
negotiations. Proposals should be entered in order of priority.
List of IPSEC Proposals: 0: New Proposal 1: genP2Proposal Enter the Number of the IPSEC Proposal [1]? Are there any more Proposal definitions for this IPSEC Action? [No]: Here is the IPSec Action you specified... IPSECAction Name = secure11To13 Tunnel Start:End = 1.1.1.1 : 1.1.1.3 Tunnel In Tunnel = No Min Percent of SA Life = 75 Refresh Threshold = 85 % Autostart = No DF Bit = COPY Replay Prevention = Disabled IPSEC Proposals: genP2Proposal Is this correct? [Yes]: IPSEC Actions: 0: New IPSEC Action 1: secure11NetTo12Net 2: secure11To13 Enter the Number of the IPSEC Action [1]? 2
ISAKMP Actions: 0: New ISAKMP Action 1: genPhase1Action Enter the Number of the ISAKMP Action [1]? Do you wish to Map a DiffServ Action to this Policy? [No]: Policy Enabled/Disabled (1. Enabled, 2. Disabled) [1]? Here is the Policy you specified... Policy Name = examplePolicySecure11to13 State:Priority =Enabled : 10 Profile =trafficFrom11NetTo13Net Valid Period =MonToFri-9am:5pm-1999 IPSEC Action =secure11To13 ISAKMP Action =genPhase1Action Is this correct? [Yes]:
This policy example shows how to configure a simple drop rule for the public interface that drops all traffic that is not secured through IPSec. This rule is very general and must have the lowest priority of any rule configured.
Policy config>add policy Enter a Name (1-29 characters) for this Policy []? dropAllPublicTraffic Enter the priority of this policy (This number is used to determine the policy to enforce in the event of policy conflicts) [5]? List of Profiles: 0: New Profile 1: trafficFrom10NetTo12Net 2: trafficFrom11NetTo13Net Enter number of the profile for this policy [1]? 0
Enter a Name (1-29 characters) for this Profile []? allPublicTraffic
Source Address Format (1:NetMask, 2:Range, 3:Single Addr) [1]?
Enter IPV4 Source Address [0.0.0.0]?
Enter IPV4 Source Mask [0.0.0.0]?
Destination Address Format (1:NetMask, 2:Range, 3:Single Addr) [1]?
Enter IPV4 Destination Address [0.0.0.0]?
Enter IPV4 Destination Mask [0.0.0.0]?
Protocol IDs:
1) TCP
2) UDP
3) All Protocols
4) Specify Range
Select the protocol to filter on (1-4) [3]?
Enter the Starting value for the Source Port [0]?
Enter the Ending value for the Source Port [65535]?
Enter the Starting value for the Destination Port [0]?
Enter the Ending value for the Destination Port [65535]?
Enter the Mask to be applied to the Received DS-byte [0]?
Enter the value to match against after the Mask has
been applied to the Received DS-byte [0]?
Configure local and remote ID's for ISAKMP? [No]:
The Source and/or Destination Address information you specified includes all addresses. You must specify an Interface Pair with this profile to further qualify what traffic you wish to filter to this policy. The interface pair should at least specify the Limit this profile to specific interface(s)? [No]: yes Interface Pair Groups: 0: New Ifc Pair Number of Ifc Pair Group [1]? 0
Enter a Group Name (1-29 characters) for this Interface Pair []? inOutPublic Ingress Interface IP Address (255.255.255.255 = any ingress) [255.255.255.255]? Egress Interface IP Address (255.255.255.255 = any egress) [255.255.255.255]? 1.1.1.1 Interface Pair Groups: 0: New Ifc Pair 1) Group Name: inOutPublic In:Out=255.255.255.255 : 1.1.1.1 Number of Ifc Pair Group [1]? 0
Enter a Group Name (1-29 characters) for this Interface Pair []? inOutPublic Ingress Interface IP Address (255.255.255.255 = any ingress) [255.255.255.255]? 1.1.1.1 Egress Interface IP Address (255.255.255.255 = any egress) [255.255.255.255]? Interface Pair Groups: 0: New Ifc Pair 1) Group Name: inOutPublic In:Out=255.255.255.255 : 1.1.1.1 In:Out= 1.1.1.1 : 255.255.255.255 Number of Ifc Pair Group [1]? Here is the Profile you specified... Profile Name = allPublicTraffic sAddr:Mask= 0.0.0.0 : 0.0.0.0 sPort= 0 : 65535 dAddr:Mask= 0.0.0.0 : 0.0.0.0 dPort= 0 : 65535 proto = 0 : 255 TOS = x00 : x00 Remote Grp=All Users 1. In:Out=255.255.255.255 : 1.1.1.1 2. In:Out= 1.1.1.1 : 255.255.255.255 Is this correct? [Yes]: List of Profiles: 0: New Profile 1: trafficFrom10NetTo12Net 2: trafficFrom11NetTo13Net 3: allPublicTraffic Enter number of the profile for this policy [1]? 3
List of Validity Periods: 0: New Validity Period 1: MonToFri-9am:5pm-1999 Enter number of the validity period for this policy [1]? 0 Enter a Name (1-29 characters) for this Policy Valid Profile []? allTheTime Enter the lifetime of this policy. Please input the information in the following format: yyyymmddhhmmss:yyyymmddhhmmss OR '*' denotes forever. [*]? During which months should policies containing this profile be valid. Please input any sequence of months by typing in the first three letters of each month with a space in between each entry, or type ALL to signify year round. [ALL]? During which days should policies containing this profile be valid. Please input any sequence of days by typing in the first three letters of each day with a space in between each entry, or type ALL to signify all week [ALL]? Enter the starting time (hh:mm:ss or * denotes all day) [*]? Here is the Policy Validity Profile you specified... Validity Name = allTheTime Duration = Forever Months = ALL Days = ALL Hours = All Day Is this correct? [Yes]: List of Validity Periods: 0: New Validity Period 1: MonToFri-9am:5pm-1999 2: allTheTime Enter number of the validity period for this policy [1]? 2 Should this policy enforce an IPSEC action? [No]: yes IPSEC Actions: 0: New IPSEC Action 1: secure11NetTo12Net 2: secure11To13
Enter the Number of the IPSEC Action [1]? 0
Enter a Name (1-29 characters) for this IPsec Action []? dropTraffic
List of IPsec Security Action types:
1) Block (block connection)
2) Permit
Select the Security Action type (1-2) [2]? 1
Here is the IPSec Action you specified...
IPSECAction Name = dropTraffic
Action = Drop
Is this correct? [Yes]:
IPSEC Actions:
0: New IPSEC Action
1: secure11NetTo12Net
2: secure11To13
3: dropTraffic
Enter the Number of the IPSEC Action [1]? 3
Do you wish to Map a DiffServ Action to this Policy? [No]:
Policy Enabled/Disabled (1. Enabled, 2. Disabled) [1]?
Here is the Policy you specified...
Policy Name = dropAllPublicTraffic
State:Priority =Enabled : 5
Profile =allPublicTraffic
Valid Period =allTheTime
IPSEC Action =dropTraffic
Is this correct? [Yes]:
This example shows how to configure and enable the LDAP policy search engine. In this example there are two LDAP directories (a primary and a secondary) with IP addresses of 11.0.0.2 and 13.0.0.1 respectively. They are both listening on TCP port 389 and the device must bind to the LDAP server as cn=router, password myPassWord. The base entry in the directory tree for the router's policies is cn=RouterDeviceProfile,o=ibm,c=us.
| Note: | Currently both the primary and secondary LDAP servers must be listening on the same port and have the same authentication credentials for the router. The DeviceProfile must be the same for the router in both directory servers. |
Policy config>set ldap primary-server 11.0.0.1 Policy config>set ldap secondary-server 13.0.0.1 Policy config>set ldap port 389 Policy config>set ldap bind-name cn=router Policy config>set ldap bind-pw myPassWord Policy config>set ldap anonymous-bind no Policy config>set ldap policy-base cn=RouterDeviceProfile,o=ibm,c=us Policy config>enable ldap policy-search Policy config>list ldap LDAP CONFIGURATION information: Primary Server Address: 11.0.0.1 Secondary Server Address: 13.0.0.1 Search timeout value: 3 sec(s) Retry interval on search failures: 1 min(s) Server TCP port number: 389 Server Version number: 2 Bind Information: Bind Anonymously: No Device Distinguished Name: cn=router Device Password: myPassWord Base DN for this device's policies: cn=RouterDeviceProfile,o=ibm,c=us Search policies from LDAP Directory: Enabled
Policy config>set default-policy
List of default policy rules:
1) Accept and Forward all IP Traffic
2) Permit LDAP traffic, drop all other IP Traffic
3) Permit and Secure LDAP traffic, drop all other IP Traffic
Select the default policy rule to use during policy refresh periods [1]? 3
List of default error handling procedures:
1) Reset Policy Database to Default Rule
2) Flush any rules read from LDAP, load local rules
Select the error handling behavior for when loading Policy Database [1]?
Please enter the set of Security Information for encrypting and
authenticating the LDAP traffic generated by the device when
retrieving policy information from the LDAP Server
Enter phase 1 ISAKMP negotiation parameters:
List of Diffie Hellman Groups:
1) Diffie Hellman Group 1
2) Diffie Hellman Group 2
Select the Diffie Hellman Group ID from this proposal (1-2) [1]?
List of Hashing Algorithms:
1) MD5
2) SHA
Select the hashing algorithm(1-2) [1]? 2
List of Cipher Algorithms:
1) DES
2) 3DES
Select the Cipher Algorithm (1-2) [1]? 2
Authentication: (1)Pre-shared Key or (2)Certificate(RSA Sig) [2]? 1
Enter the Pre-Shared Key []? test
Enter phase 2 IPSEC negotiation parameters:
List of IPsec Authentication Algorithms:
0) None
1) HMAC-MD5
2) HMAC_SHA
Select the ESP Authentication Algorithm (0-2) [1]? 2
List of ESP Cipher Algorithms:
1) ESP DES
2) ESP 3DES
3) ESP CDMF
4) ESP NULL
Select the ESP Cipher Algorithm (1-4) [1]? 2
Tunnel Start IPV4 Address (Primary LDAP Server)
[0.0.0.0]? 1.1.1.4
Tunnel End Point IPV4 Address (Primary LDAP Server)
[0.0.0.0]? 1.1.1.1
Tunnel Start IPV4 Address (Secondary LDAP Server)
[1.1.1.4]?
Tunnel End Point IPV4 Address (Secondary LDAP Server)
[1.1.1.1]? 1.1.1.3
Policy config>list default-policy
Default Policy Rule: Drop All IP Traffic except secure LDAP
Default error handling procedure: Reset Policy Database to Default Rule
Phase 1 ISAKMP negotiation parameters:
Diffie Hellman Group ID: 1
Hashing Algorithm: SHA
ISAKMP Cipher Algorithm: ESP 3DES CBC
Per-shared key value: test
Phase 2 IPSEC negotiation parameters:
IPsec ESP Authentication Algorithm: HMAC SHA
ESP Cipher Algorithm: 3DES
Local Tunnel Addr (Primary Server): 1.1.1.4
Remote Tunnel Addr (Primary Server): 1.1.1.1
Local Tunnel Addr (Secondary Server): 1.1.1.4
Remote Tunnel Addr (Secondary Server): 1.1.1.3
At this point you are ready to manage the routers in your network with the policy feature. For detailed information about the commands used to configure the required policy parameters such as profiles, proposals, transforms, and actions, see Policy Configuration Commands, LDAP Policy Server Configuration Commands, and Policy Monitoring Commands.